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(57) Video data formatting apparatus for formatting 
video data representing successive picture for a data 
handling channel having a predetermined data capacity 
per picture, comprises: 

means for receiving an input video signal represent- 
ing successive pictures, the input video signal hav- 
ing associated with it at least data defining at least 
some of the coding decisions made during an en- 
coding of pictures represented by the input video 
signal into a compressed form having group-of -pic- 
tures (GOP) format including at least one inter-pic- 
ture encoded picture; 

means for converting the input video signal into an 
intermediate compressed video signal, the interme- 
diate compressed video signal having a GOP for- 
mat in which each GOP contains fewer pictures 
than a GOP associated with the input video signal; 
means for deriving a metadata signal from the input 
video signal, the metadata signal indicating at least 
the data defining at least some of the coding deci- 
sions; 

means for generating a data quantity allocation to 
control the transcoding into the intermediate video 
signal, whereby each picture of the intermediate 
video signal is transcoded so as not to exceed a 
respective data quantity allocation, in which the 
generating means calculates the data quantity allo- 
cation for each picture to be substantially equal to: 
the predetermined data capacity per picture 
less 

the quantity of metadata for the input video signal 
GOP containing that picture divided by the number 
of pictures (n) in that input video signal GOP. 
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Description 

[0001] This invention relates to video data formatting 
and storage. 

[0002] A video data storage system has been pro- 
posed in which an input video signal having a so-called 
"long GOP" format (I.e. a group of pictures format relat- 
ed to the MPEG format, involving P and/or B frames) is 
stored as an l-frame only signal. The stored signaJ is 
then returned to the long-GOP form for output. 
[0003] As well as storing the I frame data (which al- 
lows frame-accurate editing of the video signal) some 
extra data or metadata associated with the video signal 
could be stored as well. The metadata could provide in- 
formation about how the signal was coded in long GOP 
form and so could be used to assist the output encoder 
to give better results when the long GOP output signal 
is generated. 

[0004] Two example possibilities for the metadata 
are: (a) the coding decisions used in generating the long 
GOP data, for example, vectors, Q (quantization param- 
eter) values etc., or (b) the actual long GOP bitstream 
itself, in case (a), the coding decisions would guide the 
output encoder to make similar or identical decisions to 
generate the output long GOP bitstream, and in case 
(b), when no editing has taken place the original long 
GOP data could be output directly so that an l-frame to 
long GOP recoding process is needed only at or near to 
edit points. 

[0005] Of course, in either case (a) or case (b). the 
amount of metadata concerned can be highly variable. 
[0006] In case (a), the amount of data representing 
the coding decisions can vary from frame to frame. Apart 
from any other reason, an I frame does not usually have 
any associated vectors, a P frame has one set of vectors 
and a B frame may have two sets. 
[0007] In case (b), the number of bits per frame or per 
GOP of a long GOP bitstream is not generally regulated 
to a fixed amount, but instead is controlled in the MPEG 
system by the fullness of a so-called 'Virtual buffer", an 
average desired data rate overtime and by the difficulty 
of encoding the picture content itself. So, the quantity of 
data can vary dramatically from frame to frame. Also, it 
is very difficult to synchronise to the long-GOP data on 
a frame-by-frame basis. 

[0008] In contrast, the I frame data recorded by the 
video data storage system is generally set up to aim to- 
wards a fixed data amount per frame. This is particularly 
important in a tape-based system where the capacity of 
the storage medium is strictly limited. If any metadata is 
recorded, the amount of metadata allocated to each I- 
frame must be subtracted from the available data ca- 
pacity per l-frame to give a remaining target data 
amount for the l-trame. 

[0009] The problem therefore is to store the variable- 
size metadata within a fixed data allocation per l-frame : 
and to do so in a manner which allows synchronism be- 
tween the metadata and the frames of the stored l-frame 
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signal. 

[001 0] Two possibilities for handling this problem are 
therefore: 

(i) to record an average amount of either the coding 
decision data (a) or the long GOP data (b) with each 
frame of l-frame data. This gives a predictable data 
quantity remaining for each I frame. This scenario 
is shown schematically in Figure 1 of the accompa- 
nying drawings, In which each fixed-size data allo- 
cation 10 contains a predetermined quantity of I- 
frame data 20 and a predetermined quantity of 
metadata 30. However, this means that the data re- 
corded with each l-frame recorded by the video data 
storage system may bear no relation to the partic- 
ular image represented by that l-frame. 



(II) to record data actually associated with each I 
frame alongside that I frame. This is only really pos- 

20 sible for the decision data (a), as there is not an eas- 
ily derivable relationship between long-GOP data 
(b) and individual frames of the video signal. This 
scenario is illustrated schematically in Figure 2 of 
the accompanying drawings, in which each fixed 

25 size data allocation 10 contains a variable quantity 
of l-frame data 22 and a variable, complementary, 
quantity of metadata 32. This proposal means that 
there is a good correlation between metadata and 
the l-frame data if the signal is cut or otherwise ed- 

30 ited. However, it requires the target bit rate for each 
l-frame to be altered from l-frame to l-frame. Also, 
because the amount of data varies dramatically, 
some l-f rames may be left with insufficient data ca- 
pacity for adequate coding. 

35 

[0011] In summary, there is a need for a formatting 
and/or storage arrangement which allows variable- 
length metadata which may, for example, comprise or 
be derived from a long GOP encoding of a video signal. 
40 [001 2] This invention provides video data formatting 
apparatus for formatting video data representing suc- 
cessive pictures for a data handling channel having a 
predetermined data capacity per picture, the apparatus 
comprising: 

45 

means for receiving an input video signal represent- 
ing successive pictures, the input video signal hav- 
ing associated with it at least data defining at least 
some of the coding decisions made during an en- 
50 coding of pictures represented by the input video 
signal into a compressed form having group-of-pic- 
tures (GOP) format including at least one inter-pic- 
ture encoded picture; 

means for converting the input video signal into an 
55 intermediate compressed video signal . the interme- 

diate compressed video signal having a GOP for- 
mat in which each GOP contains fewer pictures 
than a GOP associated with the input video signal; 
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means for deriving a metadata signal from the input 
video signal, the metadata signal indicating at least 
the data defining at least some of the coding deci- 
sions; 

means for generating a data quantity allocation to 
control the transcoding into the intermediate video 
signal, whereby each picture of the intermediate 
video signal is transcoded so as not to exceed a 
respective data quantity allocation, in which the 
generating means calculates the data quantity allo- 
cation for each picture to be substantially equal to: 

the predetermined data capacity per picture 
less 

the quantity of metadata for the input video sig- 
nal GOP containing that picture divided by the 
number of pictures (n) in that input video signal 
GOP. 

[0013] Further respective aspects and features of the 
invention are defined in the appended claims. 
[0014] The invention is particularly applicable to a 
system in which the intermediate compressed video sig- 
nal has a GOP format comprising only intra-picture en- 
coded pictures. 

[001 5] Preferably the apparatus comprises means for 
generating data packets (e.g. for recording on a storage 
medium such as a tape medium) each comprising: an 
encoded picture of the intermediate compressed video 
signal; and a substantially 1/n portion of the metadata 
signal associated with the input video signal GOP from 
which that picture was derived. 

[0016] In embodiments of the invention, the solution 
provided to the problem described above is to determine 
the quantity of metadata - for example, of type (a) or (b) 
- associated with a particular GOP of the long GOP sig- 
nal, and then to record that metadata in substantially 
equal segments with each of the l-frames corresponding 
to that GOP 

[0017] This allows the metadata and l-frame data to 
be associated with one another on a GOP by GOP ba- 
sis. The start of each GOP of metadata can be estab- 
lished by standard synchronising codes within a GOP. 
[0018] This solution recognises that long-GOP meta- 
data of either type is close to useless if an edit has been 
made during the GOP so there is no point having a cor- 
relation frame by frame. It also allows the target bit rate 
to be set once for all of the frames corresponding to a 
GOP 

[0019] The intermediate video signal preferably com- 
prises only l-frames, for convenience of editing. This 
would generally imply a GOP length of 1 , though that 
need not always be the case. 

[0020] Preferably the metadata is formatted to the in- 
termediate video signal in such a manner that it is re- 
synchronised at GOP boundaries - in the preferred em- 
bodiments these would be boundaries of the long- 
GOPs, but in a system where the two GOP lengths 



shared a common multiple it would take place at instanc- 
es of that common multiple of pictures. 
[0021] In some embodiments, the input video signal 
need not be a compressed signal but may instead have 

5 been compressed at some other processing stage. The 
metadata signal could indicate at least a quantization 
parameter used in encoding each picture of the input 
video signal. Alternatively, or indeed in addition, the 
metadata signal indicates at least a set of motion vectors 

w used in encoding each picture of the input video signal. 
Of course, notwithstanding that these conditions would 
in fact be fulfilled by a substantially entire compressed 
video signal, the metadata can itself be the compressed 
input video signal. 

15 [0022] The input video signal could be in an uncom- 
pressed "baseband" form and have associated with it 
(for example) a set of coding decisions relevant to its 
encoding into a compressed form, in which case the 
metadata signal is derived from the video signal by ex- 

20 trading it from the associated data. However, in a pre- 
ferred embodiment the input video signal is a com- 
pressed video signal in accordance with the associated 
GOP format. 

[0023] For convenience of operation of the apparatus 

25 and the division of metadata between pictures of the in- 
termediate video signal, it is preferred that the number 
of pictures in each GOP of the intermediate video signal 
and the number of pictures in each GOP associated with 
the input video signal have a common multiple under 

30 61 . More specifically, it is particularly convenient if the 
number of pictures in each GOP of the intermediate vid- 
eo signal is a factor of the number of pictures in each 
GOP associated with the input video signal, as this al- 
lows an easier allocation of the metadata. 

35 [0024] The invention is particularly applicable to use 
in video data storage apparatus comprising formatting 
apparatus as defined above; and a storage medium for 
storing the intermediate video signal and the associated 
metadata signal . At the output of such apparatus a video 

*o signal in the same GOP format as that associated with 
the input video signal is preferably generated, using the 
metadata if possible or appropriate. 
[0025] In the case where the metadata is effectively 
a compressed video signal itself, this can in some cir- 

45 cumstances be used as the output signal so avoiding 
any quality loss or artefacts from the coding and decod- 
ing of the intermediate video signal. However, this can- 
not be done if an edit has taken place or if the metadata 
has been corrupted through, for example, data loss (de- 

50 tectable using a conventional error correcting code). In 
order to handle the possibility of an edit interrupting a 
GOP of the metadata, it is preferred that the storage ap- 
paratus means for detecting whether an edit operation 
has taken place within a predetermined number of pic- 

55 tures of a current picture; and : if not, for using the meta- 
data signal as the output compressed video signal. 
[0026] Embodiments of the invention will now be de- 
scribed, by way of example only, with reference to the 
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accompanying drawings in which: 

Figures 1 and 2 schematically illustrate unsatisfac- 
tory methods of dealing with variable length meta- 
data in a video data storage system; 
Figure 3 schematically illustrates a video data stor- 
age system according to an embodiment of the In- 
vention; 

Figure 4 schematically illustrates a compressed da- 
ta quantity controller; 

Figure 5 schematically illustrates a data formatter; 
Figure 6a schematically illustrates a long GOP en- 
coder in a simplified form; 

Figure 6b schematically illustrates a more detailed 
version of a long GOP encoder; and 
Figure 7 schematically illustrates a data structure 
as recorded by the apparatus of Figure 3. 

[0027] Figure 3 schematically illustrates a video data 
storage system according to an embodiment of the in- 
vention. The system comprises a long GOP decoder 
100, an I frame encoder 110, a TBR controller 120, a 
tape transport 130, an I frame decoder 140 and a long 
GOP encoder 150. 

[0028] The video data storage system is arranged to 
receive a video signal in a long GOP format but to store 
it on a tape medium in an I frame format. This allows 
frame-accurate editing of the video signal in a studio en- 
vironment. The long GOP format may be, for example, 
a 15 frame format such as lBBPBBPBBPBBPBB, al- 
though the term "long GOP" here means no more than 
a GOP length greater than that used in the storage ar- 
rangement. In other embodiments the I frame storage 
format could be replaced by, for example, an IB format 
or the like. Generally it is better tor the storage format 
to have a GOP length which is a factor of the GOP length 
of the long GOP signal, or at least that they have a com- 
mon multiple under, say, 61 (60 being the lowest com- 
mon multiple of 15 and 12 picture GOPs). 
[0029] In addition to the I frame video data, the tape 
transport 130 also stores metadata. Two examples of 
the form of metadata are described here, although other 
types of metadata are applicable. The two examples to 
be described are: (a) data representing coding deci- 
sions used in originally generating the long GOP data, 
lor example vectors, quantization parameter Q, DOT 
frame type, coded block pattern etc., or (b) the actual 
long GOP bit stream itself. To cater for these two exam- 
ples, the left hand top corner of Figure 3 illustrates a 
solid line for receiving metadata of type (a) in parallel 
with the long GOP data, and a broken line showing that 
the metadata could in fact be the long GOP data itself. 
[0030] The design decision on which type of metadata 
to use may depend upon the nature of the long GOP 
dala itself. For example, in a system in which the tape 
transport 130 has a data capacity of 140Mbps (million 
bits per second), a long GOP bit stream of 51 Mbps may 
be considered to be too large, in that if the whole long 



GOP bit stream was recorded the impact oh the space 
available for recording I frame data would be too ex- 
treme and the subjective quality of the I frame-encoded 
pictures would suffer too much. On the other hand, a 
5 long GOP bit stream of, say, 22Mbps might be consid- 
ered an appropriate size for recording the whole of the 
long GOP bit stream as the metadata in accordance with 
example (b). 

[0031 ] In either case, the long GOP input video signal 
10 is supplied to the long GOP decoder 1 00 where it is de- 
coded to "baseband" (uncompressed) video. The un- 
compressed video is then re-compressed by the I frame 
encoder 110. 

[0032] The encoding by the I frame encoder 110 takes 
15 place In accordance with a target data quantity (TBR") 
set by the TBR controller 1 20. The operation of the TBR 
controller 120 will be described below with reference to 
Figure 4, but In brief it determines how much space is 
needed for the metadata and allocates the remainder to 
20 the I frame encoder. The I frame encoder is of a gener- 
ally conventional type in which factors such as a quan- 
tization parameter may be varied from block to block 
within each picture to ensure that a target data quantity 
is not exceeded. 
25 [0033] The metadata and I frame data are then re- 
corded on the tape transport 130. The formatting of the 
two data items will be described below with reference to 
Figures 5 and 7. 

[0034] On replay, which may or may not take place 
30 after an editing operation on the I frame data, the I frame 
data and metadata are recovered from the tape and de- 
multiplexed into separate data streams. 
[0035] The I frame data is decoded by the I frame de- 
coder 140 Into an uncompressed form. This uncom- 
35 pressed video signal, together with the metadata recov- 
ered from the tape, are supplied to the long GOP en- 
coder 150. 

[0036] If a decision has been made to use the entire 
long GOP bit stream as the metadata (case (b) de- 

40 scribed above), then reference is made to Figures 6a 
and 6b to describe the operation of the long GOP en- 
coder 150. On the other hand, If coding decisions (a) 
are used instead, the operation of the long GOP encoder 
150 is to re-encode the uncompressed video received 

45 from the I frame decoder into a long GOP format making 
as much use of the previous coding decisions as possi- 
ble. Of course, if no editing has taken place, it should 
be possible to re-use the previous coding decisions sub- 
stantially in their entirety. If editing has taken place, then 

so at or near the edit points (perhaps within the GOP sur- 
rounding the edit points) fresh coding decisions will 
need to be derived. 

[0037] A long GOP encoder which is capable of mak- 
ing use of previous coding decisions is described in 
55 GB9920276.4, a copy of which is placed on the file of 
the present application. The output of the long GOP en- 
coder is the required long GOP bit stream. 
[0038] Figure 4 schematically illustrates the operation 
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of the TBR controller 120. 

[0039] The TBR controller 120, in Its most fundamen- 
tal form, comprises a subtracter 1 22 which subtracts the 
quantity of metadata for each GOP, divided by the GOP 
length in pictures, from the available data capacity for 
each I frame. This generates a target data quantity TBR 
which is supplied to and controls the I frame encoder 
110. 

[0040] The variable defining the length of the metada- 
ta for each GOP may be available as part of the user 
bits or other accompanying data associated with the vid- 
eo signal. If it rs not available in any other form, however 
it can be obtained by employing a substantially 1-GOP 
delay at the input to the apparatus. Data buffered in the 
GOP delay can be examined to determine the metadata 
length for each GOP. Of course, as this is a variable 
quantity (though within limits imposed by the encoding 
algorithm), it is preferred to employ a delay sufficient to 
buffer the maximum possible GOP length. 
[0041] Figure 5 schematically illustrates the format- 
ting of data to be placed onto the tape. Metadata and I 
frame data are received by separate memory stores. 
1 32, 1 34 within the tape transport 1 30. A multiplexer 1 36 
receives data from the stores 132 and 134 and supplies 
it to an error correction code generator and formatter 
138 which formats the data into the required format for 
physically laying down on the tape. The allocation of da- 
ta within a fixed-length data unit for recording is shown 
in Figure 7 below. 

[0042] Figure 6a schematically illustrates, in a simpli- 
fied form, the long GOP encoder 1 50 in the case where 
the metadata is actually formed of the long GOP bit 
stream itself (case (b)). The uncompressed video signal 
received by decoding the I frame data is re-encoded by 
a long GOP encoding engine 152. The long GOP meta- 
data is supplied along with the newly-encoded long 
GOP signal from the encoding engine 152 to a multi- 
plexer 154 which operates under the control of an "edit" 
flag. 

[0043] The edit flag is added to user data of the com- 
pressed video data when an edit operation takes place : 
for example being generated either by the tape transport 
130 or by an editing apparatus itself. From the edit flag 
it can be determined whether an edit has been made at 
or near each picture stored on the tape transport 130 - 
for example, within one GOP-length of the current pic- 
ture. 

[0044] If an edit has been made, then the long GOP 
metadata is no longer valid and so the newly-encoded 
data from the encoding engine 152 is used instead, and 
is routed to the output by the multiplexer 154. On the 
contrary : if no edit has been made, the long GOP meta- 
data can actually be used as the output signal and so is 
routed to output by the multiplexer 154. 
[0045] The system described with reference to Figure 
6a is simplified for the purposes of explanation, so a 
more detailed description will now be provided in con- 
nection with Figure 6b. 



[0046] The reason that the apparatus is preferably 
more complicated than the simple multiplexer or switch 
shown in Figure 6a arises from three main reasons: 

5 (i) that the I frames actually recorded are stored in 

a display order, whereas frames of the long GOP 
are arranged In a compression order. Long GOP 
compression using inter-frame encoded frames in- 
troduces dependencies between the compressed 

to frames so that certain frames (e.g. I and P frames) 
have to be encoded before other frames (e.g. B 
frames) can be encoded. Similarly, at decoding, cer- 
tain frames have to be decoded before others. So, 
the order of encoding and data transmission in a 

is long GOP system Is generally not the same as the 
display order. 

(ii) that there is generally no fixed allocation of data 
capacity between the different frames of the GOP, 
so it is difficult or impossible to predict how much 
20 data of the long GOP bitstream needs to be re- 
trieved in order to decode a particular number of 
frames of a GOP. 

The effect of features (i) and (ii) is that some 
latency, or delay, has to be introduced to the switch- 
es jng system. Frames cannot be switched at any ar- 
bitrary frame boundary because the required frame 
might not yet be available in the bitstream. So, some 
or all of a decoded GOP has to be buffered for any 
switching system to operate. This latency means 
30 that it is possible to examine at least some, and pos- 
sibly all, of a GOP to detect whether an edit flag has 
been set before the switching operation has to be 
initiated. 

(Hi) that switching from one long GOP bitstream to 
35 another is not as simple as just stopping the one 
and starting the other. In fact, in many systems it is 
necessary to match the level of fullness of a "virtual 
buffer" as defined in the MPEG 2 specification. If 
the occupation of the virtual buffer is not matched 
40 very soon after a splice from one long GOP bit- 
stream to another, it is possible for the transmission 
channel or a receiver buffer to overflow (causing 
loss of data) or underflow (causing a subjectively 
disturbing gap in the decoded video). 

45- 

[0047] The last problem is specifically discussed and 
addressed in GB9920276.4 referred to above. That ap- 
plication deals primarily with splicing between two long 
GOP bitstreams, which is just the situation required here 

50 when a choice has to be made between the recovered 
metadata long GOP bitstream or a newly encoded long 
GOP bitstream by the encoding engine 152. 
[0048] Accordingly, Figure 6b includes matter derived 
from GB9920276.4, and reference should of course be 

55 made to that application for further detail. 

[0049] Referring to Figure 6b, the long GOP bitstream 
recovered as the metadata signal is stored in a buffer 
160. As described above, this allows for the latency 
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needed to recover all of the frames in the correct order 
and to be sure of recovering the frames at any stage In 
receipt of the bitstream. In the present example, the buff- 
er 160 is sized to accommodate one complete GOP of 
the long GOP bitstream^ 

[0050] An edit flag detector 1 62 detects the presence 
of an edit flag in user bits of the data buffered in the 
buffer 160. If an edit flag is detected, this indicates that 
a switch should be made to a newly encoded long GOP 
bitstream provided by a long GOP encoding engine / 
buffer 164. 

[0051] The encoding engine / buffer 164 acts on the 
decoded I frame data to generate a long GOP bitstream 
having a GOP structure frame-aligned with and identical 
to that of the long GOP metadata. Part of this process 
will involve a degree of latency or delay, but if that is not 
sufficient to match the delay introduced by the buffer 
160, further delay is included so that the two are Identi- 
cal. 

[0052] A bitstream splicer 166 operates in accord- 
ance with the teaching of GB9920276.4 to splice be- 
tween the two long GOP bitstreams while matching, at 
least soon after the splice, the virtual buffer occupancy. 
In doing this, the splicer may need to control the bit rate 
of the encoding engine 164 so a feedback path is drawn. 
[0053] The splicing operation takes place under the 
control either of the edit flag detector, in other words in 
response to a detection of an edit in the current GOP. 
or in response to a data error indicator derived in a con- 
ventional way from the ECC (error correcting codes) 
used during the recording and replay process. If the 
ECC indicates data loss in the metadata bitstream, a 
splice to the newly encoded bitstream would be made 
for at least that GOP. A delay element 168 is provided 
in case the ECC information has to be delayed so as to 
correspond to the delayed video information. 
[0054] An aspect of a long GOP bitstream splicer 
which is hinted at above is that it may take a certain pe- 
riod to match the virtual buffer occupancy after a splicing 
operation has taken place. Accordingly, it may be pro- 
vided that splices, or possibly just splices from the newly 
encoded bitstream back to the metadata-derived bit- 
stream, can be inhibited until the virtual buffer occupan- 
cy has been substantially matched after a preceding 
splice. 

[0055] Of course, the operations described above 
could be implemented in hardware, custom circuitry 
such as an application specific integrated circuit (ASIC) : 
software operating on a general purpose computer or a 
mixture of these. Such software and a storage medium 
carrying such software are considered to represent em- 
bodiments of the invention. 

[0056] Figure 7 is similar to Figures 1 and 2, though 
drawn on a different horizontal scale. It shows fixed-size 
data units 200 for recording on, for example, the tape 
medium. Within each data unit is the data representing 
an I frame and some metadata derived from the GOP 
containing the corresponding frame of the input (long 



GOP) video signal. 

[0057] Figure 7 illustrates frames from two GOPs of 
the input long GOP signal. It will be seen that the quan- 
tity of metadata associated with the two GOPs is differ- 

5 ent, but that within a GOP the metadata is divided sub- 
stantially equally between I frames and is synchronised 
to the I frame signal at the GOP boundaries. 
[0058] Header data 210 may also be i ncluded to spec- 
ify, for example, the boundary between the I frame data 

10 and the metadata or to specify whether an editing oper- 
ation has taken place at or near that frame (i.e. to act 
as the "edit flag" described above). 
[0059] It will be appreciated that references to 
"frames' can be replaced by other definitions such as 

is "picture* or "field". It will also be appreciated that the 
techniques are applicable to other types of storage ar- 
rangement such as magnetic or optical disk and the like. 
Indeed, the data need not even be stored, but could sim- 
ply be formatted for handling by a data handling channel 

20 of nominally fixed capacity. 



Claims 

25 1 . Video data formatting apparatus for formatting vid- 
eo data representing successive pictures for a data 
handling channel having a predetermined data ca- 
pacity per picture, the apparatus comprising: 

30 means for receiving an input video signal rep- 

resenting successive pictures, the input video 
signal having associated with it at least data de- 
fining at least some of the coding decisions 
made during an encoding of pictures represent- 

35 ed by the input video signal into a compressed 

form having group-of-pictures (GOP) format in- 
cluding at least one inter-picture encoded pic- 
ture; 

means for converting the input video signal into 
40 an intermediate compressed video signal, the 

intermediate compressed video signal having 
a GOP format in which each GOP contains few- 
er pictures than a GOP associated with the in- 
put video signal; 
45 means for deriving a metadata signal from the 

input video signal, the metadata signal indicat- 
ing at least the data defining at least some of 
the coding decisions; 

means for generating a data quantity allocation 
so to control the transcoding into the intermediate 

video signaL whereby each picture of the inter- 
mediate video signal is transcoded so as not to 
exceed a respective data quantity allocation, in 
which the generating means calculates the da- 
55 ta quantity allocation for each picture to be sub- 

stantially equal to: 

the predetermined data capacity per pic- 
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3. 



lure 

less 

the quantity of metadata for the input video 
signal GOP containing that picture divided 
by the number of pictures (n) in that input 5 
video signal GOP. 

Apparatus according to claim 1 , in which the inter- 
mediate compressed video signal has a GOP for- 
mat comprising only intra-picture encoded pictures. 10 

Apparatus according to claim 2, comprising means 
for generating data packets each comprising: 

an encoded picture of the intermediate com- is 
pressed video signal; and 
a substantially 1/n portion of the metadata sig- 
nal associated with the Input video signal GOP 
from which that picture was derived. 



the preceding claims; and 
a storage medium for storing the intermediate 
video signal and the associated metadata sig- 
nal. 

12. Apparatus according to daim 11. comprising: 

means for retrieving the intermediate video sig- 
nal and the metadata signal from the storage 
medium; and 

means for transcoding the intermediate video 
signal into an output compressed video signal 
having a GOP format identical to that associat- 
ed with the input video signal. 



4. Apparatus according to any one of claims 1 to 3, in 
which the metadata signal is substantially identical 
to that associated with the input video signal. 

5. Apparatus according to any one of claims 1 to 3, in 
which the metadata signal indicates at least a quan- 
tization parameter used in encoding each picture of 
the input video signal. 

6. Apparatus according to any one of claims 1 to 3 and 
5, in which the metadata signal indicates at least a 
set of motion vectors used in encoding each picture 
of the input video signal. 

7. Apparatus according to any one of claims 1 to 3, 5 
and 6, in which the metadata signal indicates at 
least a DCT frame type used in encoding each pic- 
ture of the input video signal. 

8. Apparatus according to any one of the preceding 
claims, in which the input video signal is a com- 
pressed video signal in accordance with the asso- 
ciated GOP format. 

9. Apparatus according to any one of the preceding 
claims, in which the number of pictures in each GOP 
of the intermediate video signal and the number of 
pictures in each GOP associated with the input vid- 
eo signal have a common multiple under 61 . 

10. Apparatus according to claim 9, in which the 
number of pictures in each GOP of the intermediate 
video signal is a factor of the number of pictures in 
each GOP associated with the input video signal. 



11 . Video data storage apparatus comprising: 

formatting apparatus according to any one of 



13. Apparatus according to claim 12 as dependent on 
claim 4, comprising: 

meansf or detecting whether an edit operation 
has taken place within a predetermined number of 
20 pictures of a current picture; and, if not, for using 
the metadata signal as the output compressed vid- 
eo signal. 

14. A method of formatting video data representing suc- 
25 cessive picture for a data handling channel having 

a predetermined data capacity per picture, the 
method comprising the steps of: 

receiving an input video signal representing 
30 successive pictures, the input video signal hav- 

ing associated with it at least data defining at 
least some of the coding decisions made during 
an encoding of pictures represented by the in- 
put video signal into a compressed form having 
35 group-of-pictures (GOP) format including at 

least one inter-picture encoded picture; 
converting the input video signal into an inter- 
mediate compressed video signal, the interme- 
diate compressed video signal having a GOP 
40 format in which each GOP contains fewer pic- 

tures than a GOP associated with the input vid- 
eo signal; 

deriving a metadata signal from the input video 
signal, the metadata signal indicating at least 
45 the data defining at least some of the coding 

decisions; 

generating a data quantity allocation to control 
the transcoding into the intermediate video sig- 
nal, whereby each picture of the intermediate 
so video signal is transcoded so as not to exceed 

a respective data quantity allocation, in which 
the generating means calculates the data 
quantity allocation for each picture to be sub- 
stantially equal to: 

55 

the predetermined data capacity per pic- 
ture 

less 
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the quantity of metadata for the input video 
signal GOP containing that picture divided 
by the number of pictures (n) in that input 
video signal GO P. 

5 

15. A computer program having program code for car- 
rying out a method according to claim 14. 

16. A storage medium carrying a computer program ac- 
cording to claim 15. 10 
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